תכנות-השלב הבא
הקדמה
-----
את המדריך הזה אני כותב כמין המשך למדריך הקודם שלי (מבוא לתכנות) אבל בהנחה שהלכתם למדתם
למדתם שפת תכנות אחת או יותר לעומק או לא, ושוב המדריך הזה בא כתשובה לשאלות שאני רואה בפורומים
שונים וגם דברים שאני רואה שקודי מקור של אנשים אני מקווה שמדריך הזה יוכל לעזור לכם לפתח את טכניקות
התכנות שלכם ואת החשיבה התכנותית שלכם, שבסופו של דבר יחסכו לכם זמן ותנו לכם אפשרות לעשות פרוייקטים גדולים וברמה:)
במדריך זה נתעסק בכמה שיטות תכנות שהתפתחו עם השנים כאשר כול נושא התכנות התחיל להתפתח בעולם
, רוב השיטות מופנות לכיוון שפות עיליות, כי שם נוצר הצורך בהן הרי השפות העיליות עצמן נוצרו
מצורך של פשוטת וחסיכת זמן בעבודה.
שיטות אלו צמחו בעיקר בתעשיה של התוכנה, המטרות שלהן לאפשר קיצור זמן העבודה שימוש חוזר בחלקים
של תוכנה ולאפשר להם לשנות את מטרות התוכנית , דבר שקורה די הרבה שאתה עובד עם לקוחות, שלא כמו שאתה
בונה תוכנית בשביל צורך עצמי ולפי מטרות שאתה מגדיר קליינטים מרבים לשנות ולהוסיף מטרות לתוכנית מסויימת,
שיטות התכנות האלה עוזרות לחסוך זמן כי כול חלק לומד לעבוד בצורה הכי עצמאית שהוא יכול לא צריך לכתוב
חלקים ממנו מחדש ומשתמשים בו בצורה שהוא כמו חייל קומנדו שנשלח לבצע משימה, אתה אומר לו לעשות אותה
ומכאן מפסיק הקשר ביניכם כאשר תרצה לשנות לו את המשימות או לגרום לו לבצע דבר אחר כול מה שתצטרך
לעשות זה לשלוח אותו מחדש ולא לדוגמא לעשות לו הדרכה מחדש(כתיבת חלקים מהקוד למי שלא עוקב חח).
תחילה החלו בשימוש בשיטת התכנות המובנה ואז הרחיבו אותה לשיטה שכולם מכירים כיום תכנות מונחה עצמים,
כמעט כול שפות התכנות של היום משלבות בצורה חלקית או מושלמת את האפשרות להשתמש בעיקרון זה בתוכן.
ע"י הפנמת העקרונות הללו בתוכניות שלכם גם אם הן לא גדולות או לא מתוכננות להיות גדולות תוכלו להרחיב
אותם בשניות ולהגיע לדברים גדולים:)לטווח הקצר הדברים האלה נראים מיותרים אבל לטווח הארוך הם ממש
טובים וגם צריך ליצור הרגלים בנוגע לכתיבה ככה אתם נעשים מתכנתים יותר יעילים.
תכנות מובנה
-----------
רעיון התכנות המובנה נוסח לראשונה לפני שנות השישים, הוא בא לשימוש בעיקר בחברות התוכנה העיסקיות ולמעשה
מן העבודה והפקת הלקחים בעבודה זו שיטה זו נוצרה בכתיבה תוכנות גדולות החלו להתעורר בעיות שגרמו לכך
שבעקבות רצון להוספת פונקציות למערכת או עדכון חלק מהרכיבים חלקים אחרים בקוד או אולי כול שאר הקוד
היה צריך להכתב בחלקו או כולו מחדש כי הוא לא התאים יותר, וכך נוצר העיקרון התכנותי הנקרא תכנות מובנה.
אחרי כול המילים האלה נגיע להגדרה עצמה- למעשה העיקרון בתכנות מובנה הוא לבנות תוכנה מלמעלה למטה ,
הכוונה היא שיש לחלק את התוכנה לחלקים קטנים שכול אחד מהם יבצע תת משימה וכולם ביחד יבצעו את מטרת
התוכנית, כאשר עוברים לישום הקוד כול תת משימה תתבצע ע"י שגרה - פרוצדורה או פונקציה.
שכותבים תוכניות קטנות הכול נראה מאוד לא נחוץ ונראה לנכון שעדיף פשוט להתחיל לכתוב ו"נראה מה יהיה"
אבל בתוכניות גדולות צורת עבודה זאת למעשה תגרום לבזבוזי זמן ולטעויות רבות
(כאשר משפרים קוד שוב ושוב באגים זה רק עניין של זמן).
לשיטת תכנות זאת יש כמה כללים "נוקשים" אך היא גורמת לתוכנית להיות ברורה יותר , קלה יותר לניפוי שגיאות
וקלה יותר לשדרוג הרעיון הראשי בה כפי שנאמר היא ששגרה מקבלת בזימון שלה את כול הנתונים שהיא צריכה,
כלומר אין שום שימוש במשתנים גלובלים!, או בנתונים קבועים מראש , לאחר מכן היא מבצעת את המשימה שלה
ומחזירה למשתנים שצריכים להשתנות את ערכם החדש(או במילים אחרות מעדכנת אותם)
בצורה זאת כאשר נרצה לעדכן את הקוד או אם תתעורר בו בעיה כאשר נתקן אותה לא נצטרך לתקן גם את הקוד המקורי.
האיסור על שימוש במשתנים גלובלים הוא הגיוני ביותר כי הרי אם נרצה לדוגמא להשתמש בשגרה עבור 2 משתנים
שונים דבר זה לא יהיה אפשרי אך אם נגדיר את השגרה כך שהיא מקבלת את המשתנה בזימון נוכל להשתמש בה כמה שנרצה.
בכלל הרעיון של כתיבת תוכנית בצורה מובנית עם סדר וחילוק התוכנית לפרוצדורות ופונקציות היה
חדש בתקופה, פעם(למי שמתעניין) היו כותבים את כול הקוד כמו שכותבים באסמבלי, במונחים מקצועיים
זה נקרא קוד ספגטי, כי בגלל הקפיצות כול הזמן היה הסתעפות ממקום למקום והיה מאוד קשה לעקוב
ולתקן שגיאות, לכן במסגרת התכנות המובנה שימוש בקפיצות ממקום למקום בקוד בצורה ידנית אסור.
המטרה הסופית שלנו בצורת פיתוח זו היא שהתוכנית שלנו, שבמקרה זה משגרת טיל תראה משהו כזה:
קבל קורדינטות למטרה
שגר_טיל(טיל, קורדינטות) \*(זוכרים אנחנו הרי לא רוצים לשגר סתם טיל אלא טיל שנבחר)*\
את שגר טיל לדוגמא אפשר לחלק לכמה תת משימות אך מבחינת התוכנית הראשי הטיל כאילו שוגר,
שוב שיטה זאת גם מאוד הגיונית מבחינת חשיבה אנחנו קודם קובעים איפה אנחנו רוצים לשגר את הטיל
ואחר כך כבר מתעסקים עם כול הדברים הקטנים(כמו להשיג אורניום ומדענים רוסים)
שגר_טיל(טיל, קורדינטות)
======================
\*חשוב לשים לב שאין לנו רק טיל אחד..יכול להיות לנו מערך של טילים..או טיל שקשור לאיזה גיפ וכולם ישתמשו באותה אלגוריתם:) *\
אם קורדינטות נכונות אזי
מלא_דלק_לטיל(טיל)
בצע_הכנות_נוספות_לשיגור(טיל)
שגר_טיל_למטרה(טיל, קורדינטות)
זהו והצלחנו לשגר לנו טיל:)
הבדלים\מעבר לתכנות מונחה עצמים
------------------------------
לאחר כמה זמן החליטו לשפר אף יותר את השיטה ולכלול בתוך המבנים בצורה בלתי נפרדת את הפעולות
שאפשר לבצע עליהן..וכך המבנה הפך לאובייקט והתחילו להשתמש בתכנות מונחה עצמים:)
הייתרונות הם רבים, ואין חסרונות
לידע כללי כדאי שתדעו שהשפה הראשונה שישמה את הרעיון היא Simula 67 בשנות השבעים, ובתחילת שנות
השבעים יושמה השפה שהביאה את השיטה הזאת לתפוצה רחבה הלוא היא CPP או C++
תכנות מודולרי
-------------
הרעיון בתכנות מודולרי הוא כזה, התוכניות שלך , כן כן שלך תהיינה בנויית כמו בניין של לגו, כלומר אתה תבנה
אותן מחלקים חלקם מוכנים חלקם בנית בעבר בעצמך וחלקם תבנה במיוחד בשביל הבניין(תוכנית) הזאת,
כאשר תסיים לבנות את הבניין שלך, תוכל להשתמש בחלקים שבנית במיוחד בשביל התוכנית הקודמת שוב אם
תרצה ותרגיש את הצורך בכך בבניין הבא(אולי הבניין הזה גם יהיה יותר גדול:) ) בצורה זאת תחסוך לעצמך
עבודה וזמן(שוב אני מזכיר זמן זה כסף) זה למעשה הרעיון פה.
אתה המתכנת תבנה לעצמך חלקים מוכנים שתוכל לשלב אותם בתוכניות שלך, לכול חלק יהיה תפקיד מסויים
אותו הוא ימלא בצורה עצמאית מוחלטת, הוא יכול להשתמש בחלקים אחרים שבנית אך מבחינתך באותו רגע
הוא עובד לבד, בתכנות "חלקים" אלו נקראים ספריות, בכול שפת תכנות הן נקראות קצת אחרת אך הרעיון הוא אותו רעיון.
בנוסף שימוש בחלק שלך, תוכל לבצע עליו פעולות שונות הקשורות במאפיינים שלו, לצבוע אותו, להפוך אותו
(ועוד כמה דברים שעושים על בלטה של איטונג)
כדי שהספרייה שלך תיהיה טובה היא כמובן צריכה להיות מופשטת ככול הניתן, הכי טוב מופשטת לחלוטין
בלי נתונים קבועים הכול מתקבל מן התוכנית, בצורה זו תוכל להשתמש בה באיזה הקשר שתרצה
(ראו את הסעיף על תכנות מובנה אם אתם לא מבינים על מה אני מדבר)
מתכנתים בונים ספרייות לצרכים שונים, כדי לממש מבני נתונים(עץ רשימה וכו) בשביל כול מיני המרות ועוד
מליון ואחד דברים נוספים, אחד הייתרונות הנוספים ביצירת ספרייה ובתכנות המודולרי הוא שאתה יכול
למכור את הספרייה שלך איך שהיא, דוגמא לכך היא מנוע גרפי, החברה שיצרה את המנוע הגרפי של Queke 3
מכרה אותו לאיזה מליון חברות אחרות, וכך הם המשיכו להרוויח כסף מכול הכיוונים בנוסף למשחק שלהם,
אפשר אפילו להגיד שהמשחק שלהם היה מין הפגנת יכולות של המנוע הגרפי המדהים הזה שהיה "חזית הטכנולוגיה"
עד לפני כמה שנים..את הספריות שלך אתה יכול להפוך לקבצי DLL וכך לוודא שאף אחד לא יוכל להמשיך לפתח
את הספריה שלך בלי רצונך כי הם לא יוכלו לראות את הקוד של הספרייה אלא רק להשתמש בה.
לסיום חשוב ללמוד שבספריות החלק של התיעוד הוא חשוב מאוד! גם בשביל עצמך, וגם כדי לשמש כ SDK לאנשים
שלהם אתה מוכר או נותן שימוש בספריה שלך(עוד על תיעוד בחלק הבא) עוד אוסיף שמומלץ שכול אחד מכם יכין
לצורך תרגול וגם לצורך כללי ספרייה אפילו קטנה שתכיל כול מיני דברים שכתבתם, ותוכלו להשתמש בהם חופשי
בתוכניות שלכם, דרך אגב אם אתם תוהים אם אתה מצרפים ספרייה היא לא מתווספת בצורה עיוורת לתוכנית שלכם,
רק אם אתם משתמשים באחת הפעולות שלה רק היא "מועתקת" לקוד של התוכנית שלכם אז אל תדאגה אתם יכולים
להכין ספרייה ענקית והיא לא תכביד על התוכנית שלכם גם אם תשתמשו במשהו מאוד קטן ממנה, לפעמים גם
(אם ככה זה מוגדר בקומפילציה ובספריה)אז שום חלק של הספריה לא מתווסף לקוד ובזמן ההרצה יש שימוש בספריות המקומיות במחשב.
תיעוד
-----
תיעוד בתחום התוכנה הוא דבר חשוב ביותר, כאשר הפרוייקט גדול ומצריך יותר מישיבה אחרת הוא נעשה אפילו קריטי!
כמה מילים באנגלית או בעיברית יכולים לתאר פעולה של קוד בן 100 שורות ובכך לחסוך לך המתכנת או אולי
למתכנת אחר הרואה את העבודה שלך זמן יקר (כזכור זמן = $) ישנן שיטות רבות לתיעוד תוכנה, אני אציג בפניכם
את השיטות הסטנדרטיות וגם כמה שיטות "שלי" על הדברים שלי אתם יכולים לדלג...אבל על הדברים הסטנדרטיים
מומלץ מאוד לא לדלג לא בקריאה ולא בביצוע, למרות שבשלב זה אולי כול הדבר הזה נראה לכם מאוד מיותר ובזבוז
זמן אבל תאמינו לי, אחרי שתבנו את הפרוייקט הראשון שלכם שעובר את ה 100 200 שורות, תעזבו אותו לכמה זמן
ואז שתבואו להוסיף לו משהו אתם פתאום תבינו כמה התיעוד הוא חשוב
אוקי אחרי שהסברתי לכם (באריכות יתרה אולי) למה, צריך לפרט כפי שהבטחתי:
הדבר הראשון שצריך להיות בתוכנה הוא מה המטרה שלה? מה היא עושה? אולי גם כמה פרטים על למה היא יותר טובה
מאחרות, דברים כאלה נמצאים בדרך כלל ב readme של תוכנות ממולץ להכין משהו דומה לכך לתוכנה שלכם, לווא דווקא
לצורכי פרסום אלא לצרכים שלכם שתראו לאן אתם הולכים עם התוכנה עוד לפני שהתחלתי לכתוב אותה
כך גם לעשות גיבוי לכול הגרסאות הראשיות של התוכנה שלך (או הספריה) עם דברים שהוספת ושיפרת בהם, ככה
אם פעם תרצה ללכת אחורה תדע לאן.
אחר כך בכול שגרה, זוכרים ? תכנות מובנה..הרבה שגרות לכול אחת מטרה מוגדרת, בכול אחת שאתם כותבים מציינים -
מה השגרה מקבלת (קלט) נקרא גם טענות הכניסה
כמה מילים על מה השגרה שגירה עושה וגם אולי כמה פרטים על איך היא מבצעת זאת
בצורה מדוייקת מה קרה בתוכנית או לקלטים לאחר ביצוע השגרה (אולי די דומה לסעיף הקודם אך הכרחי!)
בנוסף בכול פיסה של קוד שיש לה חשיבות או קושי מומלץ לשים הערה קטנה לדוגמא ליד משתנים , מה מטרתם מה הם
עושים וכו, ליד אתחולים של מבנים\משתנים למה דווקא הם מאותחלים ככה וכו
אני אישית משתמש בהערות במקומות שאני מקווה יום אחד לפתח לשדרג או להוסיף קטעים חדשים, ככה שכאשר אני
אעבור על הקוד אני אזכור איפה לשים אותם ובכלל אזכור שרציתי לעשות את זה פעם, דבר זה ביחוד בא לשימוש בכתיבת
השלד של התוכנית , לאחר שלב האלגוריתם נשארים שאריות שלו בקוד.
(בפלטפורמה של דוט נט יש משהו ממש חמוד שמאפשר ללכת אחר כך לדברים האלה...עושים TODO: get your dog out ותחפש את הטודוליסט זה יראה לך ויוביל לשורה)
כמה עצות\טיפים לסיום
--------------------
שהתחלתי לכתוב את הכתבה הזאת השארתי מקום לזה..אבל נראה לי שאם תעשו אפילו חצי ממה שכתבתי פה תסתדרו :)
בקיצור...תתחילו לחשוב בגדול אל תחשבו שיש משהו שאתם לא יכולים לעשות ,
יש לכם רעיון תיישמו אותו! צריכים עזרה? לא חסר איפה למצוא...העיקר תתחילו לתכנת!